Mobile IPv6 specification, as described in §5.2 of RFC-3775, explicitly mentions that its defense mechanism does not cover attacks which are launched by a malicious node located on path between a home agent (HA) of a mobile node (MN) and a particular correspondent node (CN). A malicious node refers to an attacker located somewhere on-path between the targeted MN's HA and the CN. This means that the attacker is able to spoof the content of a full home test init/home test (HoTI/HoT) messages exchange between the MN and the CN.
A malicious node can launch a session hijacking attack by spoofing the parameters carried in the HoT message sent by the CN to the MN, followed by exchanging care-of test init/care-of test (CoTI/CoT) messages using as a care-of address (CoA) an address configured on another interface. After a successful return routability (RR) exchange, a binding update (BU) message can be sent by the attacker to the CN signaling that the MN has moved to another location. Consequently, the CN may re-direct its data packets to the new MN's CoA. Such an attack will severely disrupt the traffic flow exchanged between the MN and the CN especially for time sensitive applications.
FIG. 1 is a diagram illustrating a typical return routability procedure of a MIP network. Referring to FIG. 1, when MN 101 moves to a foreign network, it obtains a CoA. A binding cache entry is created in MN's HA 102 and CN 103 that maps the MN's home address (HoA) to its CoA. Typically, a return routability procedure is performed. The return routability procedure establishes proof to the CN that the MN is reachable at both its home address (using the indirect path) and its care of address (using the direct path) and determines tokens that are used to derive a binding management key (Kbm), which is used to calculate authorization data values for binding messages such as binding update (BU) and binding acknowledgement (BA) messages.
In this example, during a return routability procedure, MN 101 sends a HoTI message to HA 102 which forwards the HoTI message to CN 103. In parallel, MN 101 sends a CoTI message to CN 103. In return, CN 103 sends a HoT message with a HoA token back to MN 101 via HA 102 and sends a CoT message with a CoA token to MN 101 directly. The MN 101 can derive a Kbm based on the HoA token and CoA token. The Kbm can be used for subsequent binding maintenance (e.g., BU/BA message exchanges) as long as the MN's HoA and CoA do not change. The BU and BA message exchange uses the Kbm to prove that the messages were sent from the nodes that participated in the return routability procedure. For the binding update, the CN verifies the included authorization data, updates its binding cache with an entry for the MN, and typically returns a BA message, which also contains authorization data calculated using the Kbm.
If attacker 104 on the path between HA 102 and CN 103 spoofs the traffic, such as HoT/HoTI messages, between HA 102 and CN 103, attacker 104 can obtain certain parameters such as HoA token (t2). Attacker 104 can use such information to impersonate MN 101 and hijack the session between MN 101 and CN 103. For example, once attacker 104 obtains the HoA token, attacker 104 can launch another CoTI/CoT exchange with CN 103 to obtain another CoA token (t3), using another CoA that is associated with attacker 104. Attacker 104 can then use the HoA token (t2) obtained from the spoofed HoT/HoTI exchange and the CoA token (t3) to form a Kbm2. The Kbm2 can then be used in subsequent BU/BA message exchange. Attacker 104 can then signal CN 103, by sending a fake, yet valid, BU message, indicating that the impersonated MN has moved to another location. Consequently, the CN may re-direct its data packets to the new MN's CoA. Such an attack may severely disrupt the traffic flow exchanged between the MN and the CN especially for time sensitive applications. There has been a lack of efficient ways to mitigate such an attack.